Modern dynamic random access memories (“DRAMs”), including single data rate (“SDR”) DRAMS, double data rate (“DDR”) DRAMs, and RAMBUS DRAMs, are internally pipelined and often use either a pair of unidirectional data busses or a bidirectional data bus to transfer data during read operations (in which data are read from the DRAM over the bus) or write operations (in which data are written to the DRAM over the bus). The internal pipelining often imposes a performance loss when the DRAM transitions from a sequence of write operations to a sequence of read operations, or vice-versa. When a bi-directional data bus is used, a turnaround time penalty associated with this bus must be incurred to implement each transition from a read operation to a write operation, or from a write operation to a read operation. During each such transition, the bus must be tri-stated for a clock cycle while the previous driver of the data pins becomes tri-stated and the current driver of the data pins is enabled. This is a cycle in which no data may be transferred to or from the DRAM, and thus results in performance loss.
Conventionally, state machines inside a DRAM manage the addresses asserted to the DRAM's cell array during both reads and writes, the data read out of the cell array during each read operation, and the data written into the cell array during each write operation. When the cell array has been placed in a read state (a state in which it can execute a read command), a finite amount of time (a nonzero performance penalty) is required to place the cell array in a write state (a state in which it can execute a write command). When the cell array has been placed in a read state, it can execute a sequence of read commands without incurring such a performance penalty. Similarly, when the cell array has been placed in a write state, a finite amount of time (a nonzero performance penalty) is required to place the cell array in a read state. When the cell array has been placed in a write state, it can execute a sequence of write commands without incurring such a performance penalty.
A typical use for a DRAM is in a system that includes an arbiter and two or more client devices (“clients”) that assert read and write commands (for the DRAM) to the arbiter. The arbiter is coupled between the clients and the DRAM and configured to apply one or more rules to determine which of contemporaneously asserted commands it will pass through to the DRAM.
We shall use the expression “read client” to denote a client whose most recently asserted command (to an arbiter) is a read command for a DRAM, the expression “write client” to denote a client whose most recently asserted command (to an arbiter) is a write command for a DRAM, the expression “current client” to denote the client whose command was most recently passed through to a DRAM by an arbiter, and the expression “current command” to denote the command most recently passed through to a DRAM by an arbiter.
We shall use the expression “set of commands” (and variations thereon) to denote one or more commands contemporaneously asserted to an arbiter, where each command in the set is asserted by a client. We shall use the expression “set of competing clients” (and variations thereon) to denote one or more clients that contemporaneously assert commands to an arbiter, where each client in the set asserts one command to the arbiter.
In order to reduce performance penalties associated with read-to-write or write-to-read transitions, it has been proposed that an arbiter (in a system of the above-mentioned type) be configured to recognize whether the current command is a read command or a write command (and thus to recognize whether the current client is a read client or a write client), and to choose the next client (whose command will be passed through to the DRAM by the arbiter) to be of the same read/write type as the current client. When two or more competing clients are of the same read/write type as the current client, the arbiter uses another criterion (or other criteria) to select the next client from among these competing clients. However, the arbiter cannot select (as the next client) a matching client (having the same read/write type as the current client) from among multiple clients (competing to be selected as the next client) when none of the competing clients is of the same read/write type as the current client. To select one of multiple competing clients as the next client (when none of them is of the same read/write type as the current client), conventional arbiters apply some other rule (or rule set) to select the next client as rapidly as is practical (and without delay).
However, the present inventors have recognized that DRAM systems (that include conventionally implemented arbiters of the described type) are subject to significant limitations. For example, they are incapable of significantly reducing performance penalties associated with read-to-write or write-to-read transitions when responding to many sequences of competing commands (e.g., a repeating sequence of multiple competing read commands followed by multiple competing write commands).